Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Creating the Pop-up menu

The initializeObject procedure calls createBrowsePopupMenu unless the menu has been disabled. This custom procedure creates the menu and its menu items as dynamic 4GL objects.

The first thing to examine is why it is necessary to pass in the procedure handle of the browser object as an INPUT parameter. The call to createBrowsePopupMenu in initializeObject looks like the following:

RUN createBrowsePopupMenu ( INPUT TARGET-PROCEDURE ).

The called procedure defines it as an INPUT parameter to be used later in the code, as shown:

DEFINE INPUT PARAMETER hTarget AS HANDLE NO-UNDO.

So why can’t createBrowsePopupMenu just reference TARGET-PROCEDURE directly, as you have seen in many other cases? For the answer, refer back to the discussion and diagrams in Chapter 1, " Writing Super Procedures for Progress Dynamics Objects." There we explained that in order for any internal procedure to refer to TARGET-PROCEDURE successfully, it must itself be run IN TARGET-PROCEDURE. In this case, because createBrowsePopupMenu is in the same procedure file as the initializeObject procedure that calls it, the RUN statement just makes the call directly. For this reason, a reference to TARGET-PROCEDURE within createBrowsePopupMenu evaluates to the handle of the super procedure browsercustom.p, not to the browser SmartObject instance itself, and this is not what the code needs. Thus, either the TARGET-PROCEDURE handle must be passed in as an argument or the RUN statement must bounce back to browsercustom.p by being formulated as RUN createBrowsePopupMenu IN TARGET-PROCEDURE. Either technique works.

The code first creates the menu object itself, as shown:

CREATE MENU hPopupMenu ASSIGN POPUP-ONLY = TRUE TITLE = "Browser Menu".

It then creates each of the following menu items:

CREATE MENU-ITEM hColsMovableItem ASSIGN PARENT = hPopupMenu LABEL = "&Move Columns" NAME = "ColsMovable" TOGGLE-BOX = TRUE CHECKED = FALSE. Etc.

Again, see the accompanying procedure file for the complete code.

Next, the procedure attaches the menu to the browse widget handle, which it has retrieved using the BrowseHandle property of the browser object. Just to clarify, the BrowseHandle is the widget handle of the browse control itself. The hTarget parameter passed in to the procedure is the procedure handle of the browser SmartObject instance, as shown:

/* Add POPUP Menu to the Browse Widget. */ hBrowse:POPUP-MENU = hPopupMenu.

Finally, the code defines trigger procedures for the MENU-DROP event of the menu itself, the VALUE-CHANGED event of the Movable Item and Sortable Item, which control the check marks on those items, and the CHOOSE event for the Save and Reset options. The PERSISTENT RUN syntax is required to associate an internal procedure such as eventMenuItemValueChanged with a dynamic menu item, as shown:

ON MENU-DROP OF hPopupMenu PERSISTENT RUN eventPopupMenuMenuDrop IN hTarget ( INPUT hPopupMenu ). ON VALUE-CHANGED OF hColsMovableItem PERSISTENT RUN eventMenuItemValueChanged IN hTarget ( INPUT hColsMovableItem ). ON VALUE-CHANGED OF hColsSortableItem PERSISTENT RUN eventMenuItemValueChanged IN hTarget ( INPUT hColsSortableItem ). ON CHOOSE OF hSaveItem PERSISTENT RUN eventMenuItemChoose IN hTarget ( INPUT hSaveItem ). ON CHOOSE OF hResetItem PERSISTENT RUN eventMenuItemChoose IN hTarget ( INPUT hResetItem ).

Note that it is important for the trigger definitions to specify that the event procedure is run IN TARGET-PROCEDURE. Because TARGET-PROCEDURE itself is not available here, as noted, they do this using the procedure handle hTarget that was passed in as a parameter. In this way, the individual trigger procedures can correctly reference TARGET-PROCEDURE themselves.